Computer system virtualization allows multiple operating systems and processes to share the hardware resources of a host computer, ideally, the system virtualization provides resource isolation so that each operating system does not realize that it is sharing resources with another operating system and does not adversely affect the execution of the other operating system. Such system virtualization enables applications including server consolidation, co-located hosting facilities, distributed web services, applications mobility, secure computing platforms, and other applications that provide for efficient use of underlying hardware resources.
Existing virtualization systems, such as those provided by VMWare and Microsoft, have developed relatively sophisticated virtualization systems that are architected as a monolithic virtualization software system that hosts each virtualized system. In other words, these virtualization systems are constructed to host each of the virtualized systems on a particular computing platform. As such, the virtualization systems or virtual machine monitors (VMMs) associate hardware resources of a particular platform with each partition. Typically, this involves sharing of resources across multiple partitions. For example, two partitions may share a same processor and memory resource (although may be separated by address ranges or otherwise maintained to ensure isolated memory management). Furthermore, two such partitions may also share input/output devices, such as keyboards, mice, printing ports, Ethernet ports, or other communications interfaces.
Recently, technologies have been introduced that simplify sharing of I/O devices in a computing system across a plurality of virtual machines. Such technologies include Single-Root Input/Output Virtualization (SR-IOV), which allows a single physical device to be made available to multiple separate virtual devices without requiring the virtualization system to manage time-sharing of the device across such virtual machines that wish to share the I/O device. In particular, SR-IOV is intended to standardize a way of bypassing a VMM's involvement in data movement by providing independent memory space, interrupts, and DMA streams for each virtual machine. SR-IOV architecture is designed to allow a device to support multiple Virtual Functions (VFs) while minimizing the hardware cost of each additional function.
SR-IOV-compatible I/O devices are defined by two primary function types—physical functions (PFs) and virtual functions (VFs). Physical functions are full PCIe functions that include the SR-IOV Extended Capability, which is used to configure and manage the SR-IOV functionality. Virtual functions are ‘lightweight’ PCIe functions that contain the resources necessary for data movement but have a carefully minimized set of configuration resources. Each virtual function is associated with a physical function, and relies on the physical function for execution.
The SR-IOV specification includes a header type that allows for definition of whether a particular device supports multiple physical functions. However, use of this header type has limitations. For example, although the SR-IOV specification allows for multiple physical functions to be associated with a single device, typical correspondence between physical and virtual functions (by way of a bus identifier, device identifier, and function identifier) remains unchanged, leading to use of a single virtual function per partition that is associated with the physical function. This leads to limitations in terms of configurability within some virtualization architectures.
Additionally, because existing SR-IOV technologies are managed entirely by the VMM associated with a particular virtualization architecture, such I/O devices are dependent upon continued operation of the VMM for continued proper operation of the I/O device. Additionally, by managing the SR-IOV instance, and in particular the physical function, the VMM is required to directly manage I/O functionality, rather than allowing an operating system or some other system specialized to that task. Additionally, because such VMMs are typically a monolithic software system, in case of failure of such a VMM, the entire I/O device will become unusable in such circumstances. Furthermore, flexibility of configuration is also limited based on the typical implementation of SR-IOV.
For these and other reasons, improvements are desirable.